I've been working on the digging code for leprechaun and have it working; mostly. Unfortunately there's a bug, or rather an unanticipated side effect. The problem is if an enemy falls in a hole and it starts to fill up, the bitmap for gold is momentarily displayed. But then the enemy picks up the "gold", but the fill continues, leaving the enemy stuck in a (top) half filled hole.

The "easy" fix is to change the gold bitmap, i.e. remove the bottom white line, so it doesn't match half filled dirt. Easy from a code perspective, but a pain because I've got to redo the level bitmaps to change the gold. However, maybe this would be a good time to add the "reset gold" mini bitmap. The reflected playfield shouldn't be too hard since it's just some bit rotations which I can automate easily. (More code changes for that.)

I'll put out another WIP release as soon as this gets fixed. (Maybe with more sprites too.)

 lep1129.zip ( 10.75k ) : 28
Thanks to Ben Langberg, Leprechaun now has sprites.

Thanks to Manuel & Thomas, I've managed to trim 13 whole lines of CPU time off the blit routine. I still need to work on their suggestion of changing the playfield to reflected. That will take some more effort. I also have plans to squeeze in REFP0/1 logic, which will reduce the ROM space needed to store the sprites (since right now I have to store both right & left versions).

Other major to-dos (not necessarily in this order):
1. Add the dig/fill logic.
2. Scoring w/ score & life display
3. Restarting the current level (reset gold)
4. Loading the next level
5. Enemy+Enemy collision detection. (Hmm, maybe bounce away?)
6. Multi-color sprites (depends mostly on cycles in the kernel)
7. Title / end screens, music, High Score cart & AtariVox support, etc. (including support for Glenn's joy2serial auto-load fob)

Whew! I'm going to need all 8 months to get everything done!

 lep1125.zip ( 11.04k ) : 14
Well, I mentally looked at the list to Leprechaun to-dos and decided that I needed to tackle the BLIT routine next. This is the code which copies the sprite graphics (running etc) from ROM to the strips of SuperCharger RAM that the kernel then uses. (Much like the 5200 & A8s.)

And I'm glad I did, because I discovered (to my horror) that the routine barely fits in the time between the end of VSYNC and the start of the kernel. (Actually, I had to increase that time by a couple of lines even.) Each player & enemy typically needs over 600 CPU cycles to handle, with close to 500 cycles being the actual BLIT. (The rest being figuring out which player sprite gets used and setting up the BLIT.)

I'm now a little concerned that I'm going to run short on time to squeeze the remaining features into the time between then end of the kernel and the start of VSYNC. (I'm particularly worried about adding a score display since that will automatically chew up a bunch of lines.)

Anyway new features in the attached binary:
- The colored blocks are now the right number of lines high. This really shows off the intelligent flicker.
- player now changes color when dead

 lep1123b.zip ( 9.26k ) : 7
Okay, I've killed all of the player movement bugs. So you can now move around the screen. Hooray! No digging yet, though. (That's a whole different kettle of fish.)

I was working on getting the enemy movement working, but there's a glitch with moving left and they just slide off the edge of the screen. Ooops. I've bypassed that code in this build, but I'll work more on it tonight. <EDIT> Fixed! New binary! I've also made the enemies white when they are hunting, and green when they are chasing.

There's lots more code to do, but now I've got a stable base to work from I'll be able to incrementally add features and test them out. So from now on each new release will be (hopefully) bug free.

 lep1122.zip ( 9.02k ) : 9
I am slowly tracking down the bugs in Leprechaun, primarily using the Stella debugger, with some z26 tracing.

Anyway, just for laughs, I've found the following glitches so far:
- used a BCS instead of a BNE which caused the player to climb off the top of the screen
- forgot that the sprite positions are already shifted 2 pixels by the positioning routine, removed the redundant shift. (Although my first attempt to do so caused more problems because I over-optimized.)
- logic glitch in translating the Y position to sprite table which mucked up the climbing / falling

My next problem is the player seems to be falling into the dirt. I have a feeling the problem is the vertical bitmap to byte value is reverse what I thought it would be.

I'm actually somewhat impressed that I've only found a small number of bugs in ~900 lines of code.

I'm also re-proving to myself that working on it every day, even for a little while, is better than waiting for the free time for a marathon session.

<edit> Yes! That's 90% of the problem. Changed the GRID code to use ROL rather than ROR and bingo. The player still falls down ladders for some reason, but the base logic seems to be working. I think this is deserving of an attachment.

I hate it when I stop working on a programming project for too long. I forget stuff, except for the problem I couldn't figure out or solve. Which doesn't provide me with much incentive to pick it back up. Thus I forget more & it's even more difficult to actually fix whatever roadblock I hit.

Leprechaun has a problem. What should be a static display isn't. Enemies are moving (although they may be simply falling, although I didn't think I had added that subroutine into their logic yet) and the player disappears after a couple of seconds. Something's f**k'd up and I'm not sure where to start looking.

Part of the problem is I had to put too many pieces together at once. There just wasn't an easy way to add features incrementally. So now I've got a big whack of new code.

But I have a plan, or at least a concept. Since the display is supposed to be static, I should be able to split Z26's trace log into separate files by frame, then use WinDiff to identify what is changing or at least when it's changing. That should then get me back towards the chunk of code which could be causing my current headaches.

I promise, as soon as I have somthing which is reasonably stable I'll post it here.

Okay, I've finally managed to get everything (back) into something which I can assemble into a 8448 byte bin. I haven't attached it because I haven't flushed out, what will probably end up being obvious, bugs. One of the problems with the code is I've started & stopped so many times I've forgotten dependencies and made some errors. It's also been a long while since I've had something which I could run and debug.

One bonus is it appears I should be able to fit the game code into 4K, although it's organized a little differently than the previous version. I've moved the level data into Bank 3 and started the kernel at $1000 since it can work in read-only mode.

Oh, and it does look like there's the possibility to squeeze a STA REFPn into the kernel, and I've figured out an interesting way to load the bit too.

My main annoyance right now is the screen only stays stable for a short period of time, then it goes a little wacky and gets worse. Probably a rogue SuperCharger write which is mucking up the kernel. i should be able to find it with Z26's trace log. I haven't tried out the Stella 2 debugger yet.

I was thinking yesterday about the various differences between Leprechaun and Lode Runner and came up with the following list (subject to change):

- no end of level ladder
- no hidden pits / traps
- enemies pick up, but don't drop, gold
- multiple enemies can fall into the same hole
- can't run over enemies in the hole (player falls in the hole & dies)
- enemies can't climb out of holes (they "die" and reappear at the top)
- enemies can fall & run through holes, same as player (until the hole starts to fill)

Most of these differences are a result of only using the background bitmap movement handling. Although it's probably possible to duplicate the enemy/hole behaviour of Lode Runner, it would take more code & effort. It will be interesting to see how these differences change the gameplay. One obvious item is you will only need to dig a single hole to capture all of the enemies, but then you will have to wait for the hole to fill before moving over where the hole was.

Enemies not dropping the gold they pick up is because I can't easily prevent having gold reappear in a non-open grid location. There's are just too many variables & situations. Thus, I'm thinking the scoring will reflect this, and part of the objective for each level will be to pick up as many gold as possible, maybe with a bonus for picking up the last gold to end the level.

More of the same. I think I've got almost everything in one file, though I haven't worked up the courage to see how many bytes it assembles to. I think I'm going to try to put the enemy movement into this version too, though maybe I should turn off the collision detection if I do.

Hmm, one item I rediscovered was the sprite color is handled on a per-sprite basis. I think my original plan was to use that to mark whether enemies were carrying gold or not. I've since abandoned that idea (or at least back-burned it) since I can't put gold back at any spot on the playfield.

Anyway, I'm thinking that I can use the enemy color as a debugging tool to watch their hunt / chase status, and maybe as a collision detection indicator.

Lesee, oh yeah. I had an idea of handling the "what if I'm over 4K" problem. In the previous version I had bank 1 ($1000-$17FF) dedicated to the RAM/ROM foreground & background bitmaps, and bank 3 ($1800-$1FFF) dedicated to the actual code, with bank 2 ($1000-$17FF) reserved for the load routines. Well, if I move the background bitmaps to bank 3, then I can use bank 2 for any code (like the player & enemy movement handlers) which doesn't need to access the forground bitmaps.

Okay, to-dos for the next build:
1. Enemy AI & movement. Could leave this out, but 75+% of the code is sitting in my head waiting to come out anyway.
2. Initialization routines / static data. Probably not the final version, just something that works well enough to bootstrap the rest of the code.
3. Re-banking & bankswitch routines + re-ORGing. I'm dreading this part, 'cause it won't be fun or pretty. Again, probably just enough to get things working. Gotta remember that $10xx is write-only in write mode, so be careful putting code there for bank 2. (foreground bitmap for bank 1)

Plans for the build after that:
1. Zap/Dig/Fill routine. I think I did some of the code for this.
2. Sprite BLIT. I have a feeling this is going to either be very painful, or very easy. Might be able to make use of one of the SkipDraw variants rather than coming up with some god-awful code on my own.
3. Hmm, might be a good idea to actually have some sprites to use. Anyone want to offer to draw some for me?

That should get down 90+% of the gameplay. Also need to talk to Kirk Israel about the Leprechaun level editor he did way back when & get it revised for what I need now.

Time, she be precious and in scarce supply. I'm trying to put together all of the various bits & pieces I've written or thought about and make something a little closer to a playable version. My current goal is to get most of the player logic done so you'll be able to move the little block around with the joystick.

Most recently I've been working on player joystick handling for when the player isn't "on grid". I want to allow the player to reverse direction in "mid stride" as it were. Hopefully this will make the game feel more responsive. This then lead me to thinking about the equate values for the various actions (Run_Right versus Run_Left) to make it simplest to reverse those directions with an XOR. Which then lead me to think about action to sprite lookups, and how to do that efficiently.

It's all inter-related. Lots of back & forth. Making tweaks in one part of the code to make it more efficient (less cycles & bytes), then trying to then make sure you've fixed any cross dependencies & assumptions in other parts of the code. i.e. I decided to bit encode the actions, with the 2 LSbits being taken from the current position (or dig counter) for easy animation and the next LSbit being a direction (L/R or U/D). So now I've got to go back through the code and sync up anything where I assume the L/R bit was a different bit.

Which then brings me to thinking about sprites. To start with I need 8 running sprites (4 left, 4 right), 8 swinging sprites, 4 climbing sprites & 8 zapping sprites. Unfortunately, I can't figure out how to squeeze a STA REFPn into the top of the kernel so I have left & right duplicates. That's a total of 28 sprites. Now, I know that each level uses 4 pages (256 bytes) of data: 160 bytes for the background, 20 bytes for the gold; which leaves 76 * 4 bytes for other uses, like the sprites. A 8 bytes per sprite, that means I can have 36 different sprites. Enough for my basic needs, but not enough to have separate player & enemy sprites unfortunately. I've also got to figure out how to efficiently copy those sprites into the 16 byte high blocks the foreground bitmap uses.

I'm dripping in glue logic.